NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/149

Internet Message Format | 1996-08-06 | 5.8 KB

From: John Max Skaller <[e-mail]>
Message-ID: <[e-mail]>
X-Original-Date: Sat, 27 Jan 1996 02:16:38 +1000
Path: in1.uu.net!bounce-back
Date: 26 Jan 96 19:17:20 GMT
Approved: [e-mail]
Newsgroups: comp.std.c++
Subject: Re: auto_ptr again
Organization: MAXTAL
References: <[e-mail]> <4djrn4$[e-mail]>
X-Mailer: Mozilla 2.0b6a (WinNT; I)
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMQkpx+EDnX0m9pzZAQF+RQF+M9p3YyDCSKCvTpYbc9FVCjto8V0bb0jD
    6JkXL5mi/s7OFWgJVmfIvS8SXvOpxQts
    =sMfr

Steve Clamage wrote:
>
> In article [e-mail], "Eugene Radchenko"
> <[e-mail]> writes:
> >I would like to suggest returning to the definition of auto_ptr. The fact
> >is, in current form it is almost unusable for most things due to its
> >underlining concept of a single strict ownership. Actually, we need
> >multiple-instance auto_ptr.

> That point has been beaten to death in the C++ committee and also in
> this forum. Some people felt an auto_ptr should be able to have multiple
> owners, but people with experience with this kind of design persuaded
> the committee that auto_ptrs are too hard to use unless they can have
> only a single owner. Thus, ownership is transferred upon copying.

    This is fairly biased picture -- from my perspective.
    Here's what actually happened -- from my perspective.

    1. There was a clear need from some kind of automatic
       storage management for pointers, particularly in the light of
       exceptions.

    2. Australia, New Zealand and the UK made "Exception safe programming"
       with pointers National Body Issues. Not everyone was happy at
       having to deal with this. [In retrospect, they might have been
       right.]

    3. I submitted the first design to the Library reflector.
       The class was called "Holder". Mike Vilot (LWG leader) did some
            [[ Moderator's note: for the uninitiated,              ]]
            [[ "LWG" == "Library Working Group". -moderator (fjh). ]]
        work on it. Holder had an important property -- it was NOT copyable.

       I also said a reference counted smart pointer type
       was necessary, although I didn't have an adequate design handy.
       This was the kind to use when you needed copyability.

    4. The design was eventually taken over by Greg Colvin.
       (Greg is a top designer, his first proposal was extremely
        ambitious -- garbage collection!)

    5. Despite REPEATED attempts, Greg was not able to engineer
       a proposal for a reference counted pointer that the committee
       could agree on. [But I currently use his design myself,
       it will be published in my book as "ColvinPtr"]

    6. Because this left a huge gaping hole, the Holder class -- which
       had been renamed "auto_ptr" by this time, was mangled to try to
           serve two masters. The semantics were changed to
       "token passing", which was never in my original Holder class,
        nor implied by a reference counting implementation,
       and does not, in my opinion, meet Australia's requirements.

    7. Then it was discovered that the current specification is useless
       because it requires a non-const argument to the copy constructor.

    8. Just today I read Greg has proposed using "mutable" to fix
       the problem.  The semantics have changed radically in this
       proposal: now ALL the auto_ptr objects can access the
       object, but only one is designated as the owner.

    For the record, I have no objections to token passing per se --
it's just another storage management idiom. What I object to is the use
of copy syntax for a non-copying operation, and the fact that this
idiom is far less useful than reference counting, and not constrained
enough for a Holder style class.

    It is, for example, useless as a replacement
for pointers in classes whose constructors might throw exceptions,
since copying the object silently transfers ownership. The new
object will then promptly destroy the delegee object, invalidating
the pointer in the old one prematurely.

> That is, single ownership is a deliberate design decision based on the
> semantics an auto-ptr should have. It is not an implementation issue.

    I do not agree. It is definitely an implementation
issue when the proposed semantics are unimplementable without
resorting to hackery -- in this case "mutable".

    And the current attempt to fix the problem is an not an example
a deliberate design decision, but a brilliant designer trying
to cope with the political situation in the committee -- changing
the specification of auto_ptr is acceptable, creating
a new class is not.

> Unless someone can present new evidence that shows the arguments in favor
> of single ownership are wrong, and in addition shows that multiple
> ownership is always better, this subject won't be reopened in the committee.

    I don't agree with that either. You are making
the committee sound logical. It isn't. It is political.

    The committee will (correctly, IMHO), not reopen
the issue unless a National Body (or three!) requires it.
No amount of argument or evidence is relevant. The committee
will tolerate fudging the semantics of the existing class,
but won't address the _original_ National Body requirements.

    Will I find myself annoyed at this outcome, the need
to stablise the language overrides any but the most
fundamental design faults in the core language itself -- IMO.
So we may have to live with auto_ptr -- but we don't HAVE to
use it.

--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   [phone]
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: [e-mail]
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]